To support the enhancements introduced by the USB 3.0 specification, a new generation of USB 3.0 host controllers is required. While multiple USB 3.0 host controller implementations are possible, many of the major controllers released to date are compatible with the eXtensible Host Controller Interface (xHCI) specification.
Key motivations for adopting new host controllers such as xHCI include:
-
Unified speed support
Combining legacy USB 2.0 low-speed (LS), full-speed (FS), and high-speed (HS) transactions with USB 3.0 SuperSpeed (SS) transactions. This is essential for handling high-bandwidth bulk streaming transfers to large-capacity mass storage devices. -
Improved power efficiency
Enhanced power management at both the bus/device and platform levels, which is increasingly important given the rapid growth of mobile and embedded battery-powered platforms. -
Optional virtualization support
Modern platforms often run multiple operating systems within virtual machine (VM) environments. Host controllers may leverage the PCI Express Single-Root I/O Virtualization (SR-IOV) model and incorporate hardware-level support to reduce the software overhead on virtual machines.
xHCI vs. Legacy Host Controllers
Unlike USB 2.0 companion controller architectures that require separate EHCI + UHCI/OHCI controllers, xHCI provides a single controller for all USB speeds.
| Feature | UHCI/OHCI + EHCI | xHCI |
|---|---|---|
| Speeds Supported | LS/FS (UHCI/OHCI) + HS (EHCI) | LS, FS, HS, and SS — all in one |
| Number of Controllers | 2+ per port set | 1 |
| Driver Complexity | Multiple drivers required | Single unified driver |
| Memory Polling | Periodic polling of transfer descriptors | No polling — uses doorbell registers |
| Power Efficiency | Lower (constant memory polling) | Higher (event-driven) |
| Companion Controllers | Required | Not required |
xHCI Architecture Overview
The xHCI controller is organized around several key components:
Host Controller Registers
- Capability Registers — Read-only; describe controller capabilities (max ports, max slots, etc.)
- Operational Registers — Control run/stop, device slot management, and command ring pointer
- Runtime Registers — Manage interrupters and event rings
- Doorbell Registers — One per device slot; used by software to notify the controller that work is available
Data Structures in Host Memory
xHCI defines a set of data structures that reside in host system memory:
- Device Context — Stores the state of each USB device (one per device slot)
- Transfer Ring — A circular queue of Transfer Request Blocks (TRBs) that describe individual data transfers
- Command Ring — Used by software to issue commands to the controller (e.g., enable slot, configure endpoint)
- Event Ring — Used by the controller to report completion status back to software
Doorbell Mechanism
- Software places TRBs on a Transfer Ring for a specific endpoint
- Software writes to the device's Doorbell Register to notify the controller
- The controller processes TRBs and performs the USB transactions
- The controller writes completion events to the Event Ring
- An interrupt is generated to notify software
This event-driven model eliminates the need for periodic memory polling, which is a major power savings benefit over legacy EHCI controllers.
Device Slot Management
- xHCI supports up to 256 device slots (configurable)
- Each attached USB device is assigned a slot with its own:
- Device Context (containing endpoint contexts)
- Doorbell Register
- Slot assignment and deallocation are managed via the Command Ring
Interrupters and MSI/MSI-X
- xHCI supports multiple interrupters, each with its own Event Ring
- This enables:
- MSI/MSI-X interrupt support (Message Signaled Interrupts)
- Load distribution across multiple CPU cores
- Efficient interrupt handling for high-throughput scenarios